Подключение метода /api/v1/auth/error-directory на API-Шлюзе
Чтение HTTP-заголовков версии, проброс в gRPC Auth и сериализация справочника в JSON контракт.
NoteКраткая карточка задачи
- Репозиторий / Компонент:
backend-api(API Gateway / Шлюз). - Категория: Подключение метода к шлюзу.
- Контракт взаимодействия: Внешний
GET /api/v1/auth/error-directory-> Внутренний gRPCAuthService.GetErrorDirectory. - Спецификация gRPC контракта: См. Раздел: Protobuf Контракт: GetErrorDirectory
- Статус: Готово к реализации
WarningОграничение публичной документации
В открытом доступе представлена демонстрационная версия задачи. В настоящей публичной документации отображены не все шаги, технические сценарии и приватные эндпоинты для системы цифровых симуляторов бизнес-процессов.
- Полная спецификация метода: Доступна только во внутреннем контуре разработки (Confluence / Swagger Enterprise).
- Для получения доступа: Обратитесь к системному аналитику или Product Owner вашей команды.
- Предварительные условия (Prerequisites):
- Убедиться, что клиентские gRPC-стабы (stubs) для сервиса
AuthServiceуспешно сгенерированы и обновлены в зависимостях репозитория шлюза на основе актуального Protobuf Контракта.
- Убедиться, что клиентские gRPC-стабы (stubs) для сервиса
- Инструкция по шагам:
- На Шаге 1-2 (Обработка HTTP-запроса): Зарегистрировать внешний HTTP эндпоинт
GET /api/v1/auth/error-directory. Извлечь обязательный Query-параметрapp_langи заголовокX-App-Version. Если заголовок версии отсутствует, возвращать клиенту статусHTTP 400 Bad Request. - На Шаге 3 (gRPC Вызов): Пересобрать извлеченные параметры в gRPC-структуру
DirectoryRequest(гдеapp_version = X-App-Version,language = app_lang) и направить запрос в микросервисauth-service. Обеспечить сквозное логирование поставляемого заголовкаX-Request-ID. - Трансляция бизнес-ошибок: Если бэкенд возвращает статус-код
INVALID_ARGUMENT(передан неподдерживаемый язык), прерывать выполнение и возвращать внешнему клиенту ответHTTP 422 Unprocessable Entity(согласно Спецификации Ошибок Валидации). - Сериализация ответа согласно JSON Schema (Шаг 7): Полученный от gRPC бэкенда массив
repeated ErrorItemсериализовать в валидный JSON-пакет. Выходной формат данных должен строго соответствовать следующей JSON Schema контракта ответа:
- На Шаге 1-2 (Обработка HTTP-запроса): Зарегистрировать внешний HTTP эндпоинт
{
"\$schema": "https://json-schema.org",
"title": "ErrorDirectorySyncResponse",
"type": "object",
"required": ["status", "error_directory", "synced_at"],
"properties": {
"status": { "type": "string", "enum": ["success"] },
"synced_at": { "type": "integer" },
"error_directory": {
"type": "array",
"items": {
"type": "object",
"required": [
"system_trigger",
"grpc_status",
"http_status",
"canonical_code",
"localized_text",
"ui_reaction"
],
"properties": {
"system_trigger": { "type": "string" },
"grpc_status": { "type": "string" },
"http_status": { "type": "string" },
"canonical_code": { "type": "string" },
"localized_text": { "type": "string" },
"ui_reaction": { "type": "string" }
}
}
}
}
}